我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。

我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。

最近參與客戶 ERP 導入的過程，由於我的角色是客戶的技術顧問，我得以從一個比較客觀的外部角色，來看 ERP 廠商的顧問如何協助導入，以及客戶端派出的營運人員，如何表達營運流程和理解系統功能；我覺得這個過程滿精彩的，不但看到很多導入過程的狀況，也能藉此反思一下我要如何做的更好。

這間公司原本就有 ERP，也已經有既定的採購、生產、料號、BOM 與庫存流程。各部門的人並不是不知道自己每天在做什麼，採購知道怎麼下單，物控知道怎麼看需求，生管知道怎麼安排備料，業務也知道什麼情況下需要建立新的料號。新 ERP 顧問進場之後，一邊介紹系統功能，一邊和各部門確認未來流程，看起來是在把原本的工作方式搬到新的系統裡，但幾次討論下來可以看到，真正花時間的部分，往往是把原本依靠經驗運作的規則說清楚。所以，這篇文章會比較關注「需求訪談」的面向來切入。

原本很明確的採購規則，很快就出現例外

其中一次在介紹採購流程時，顧問先示範銷售訂單產生需求之後，可以直接轉成採購單，不需要經過請購。客戶很快就說，這條路在他們公司應該不需要，因為採購一定要先經過請購，而且請購還要先經過一層審核，所以連「直接產生採購單」的功能都可以鎖起來，避免使用者繞過請購流程。從系統設定來看，這已經很接近一條完整規則：沒有來源請購單，就不允許建立採購單。

大家剛確認完「所有採購都先請購」，現場就有人接著問，如果是自己直接下的項目要怎麼處理，並舉了委外檢驗的例子。有些產品會送到外部做檢驗，產生代檢費，現行做法可能就是直接處理。於是原本已經很清楚的採購規則，又必須重新確認委外檢驗到底算不算同一類採購、需不需要建立料號、需不需要請購，以及它應該被當成商品採購、服務採購，還是另一種費用流程。

類似的情況也出現在料號建立流程。顧問在介紹新料號時，示範了一套較完整的產品開發流程：需求可以先進入開發提案，經過審核之後，再正式建立新的料號。顧問介紹到這裡時，使用者問了一個很直接的問題：「是不是所有的新料號都一定要透過這樣的流程？」顧問這時才進一步說明，前面介紹的是系統支援的一種做法，這個流程不是必要條件，也可以透過參數控制，公司的實際規則仍然要另外確認。

採購流程裡還有另一段討論，是請購單上到底要不要顯示價格，以及請購人員能不能修改供應商。隨著對話繼續，才逐漸確認現場的角色差異：誰是物控、誰是生管、誰是採購，以及供應商最後由誰決定。顧問後來提出，物控在提出請購需求時未必需要知道價格，請購單甚至可以不帶單價，等轉成採購單之後，再由系統帶入最近一次的歷史價格給採購人員使用。

這三段討論的內容不同，一個談採購來源、一個談料號建立、一個談價格權限，但共同點都很接近：一開始聽起來已經很明確的流程，只要繼續往適用情境、角色與例外追問，很快就會出現需要重新定義的地方。

企業有流程，但很多規則仍然留在人腦裡

從這些對話來看，導入方並不是沒有流程，也不是使用者不知道自己在做什麼。比較接近的狀態是，公司已經有一套足以支撐日常運作的工作方式，但是很多條件、例外與判斷仍然留在人與人的默契裡。

使用者說「所有採購都要先請購」時，很可能是在描述自己最熟悉、最常發生的正常流程。這個回答對日常工作而言已經足夠，因為遇到委外檢驗這類特殊狀況時，可以再找熟悉的人判斷，或沿用過去處理類似案件的方法。但系統要把這句話變成一條 constraint 時，適用範圍就必須更完整，只要存在一個合理例外，就需要再把條件拆清楚。

新料號的案例也有類似情況。顧問示範「開發提案、審核、建立料號」的完整流程時，這套流程在系統裡是成立的，但公司實際上未必希望每一種新料號都走相同程序。如果沒有繼續確認哪些料號屬於真正的新產品開發、哪些只是規格延伸、哪些只是新增採購品項，最後就很容易把一個系統提供的流程直接變成組織規則。

請購價格的案例則反映出另一種隱性規則。表面上只是在討論欄位要不要顯示，實際上牽涉的是物控與採購的責任邊界。物控需要表達的是數量與需求，採購負責的則可能包含供應商與價格。當這些責任沒有先被說清楚，系統畫面上的一個欄位，就會同時混入權限、責任與工作分工的問題。

所以企業原本的 SOP 很可能已經能回答「下一步做什麼」，但還沒有完整回答「什麼條件下要做不同的事情」、「誰負責判斷」以及「哪些情況可以例外」。

「現在怎麼做」只能回答一部分需求

一般流程訪談很容易沿著正常路徑往下問，例如訂單進來之後做什麼、下一個部門是誰、建立哪一張單據、主管在哪裡審核。這些資訊當然重要，也可以畫出相當完整的流程圖，但如果訪談停在這裡，還不一定足以支撐系統設計。

例如客戶說：「所有採購都要先請購。」

如果訪談的下一個問題只是「請購完之後呢」，委外檢驗這個例外可能一直到系統上線後才被發現。

客戶說：「新料號需要審核。」

如果接下來只問「誰審核」，也可能漏掉不同類型料號是否應該適用相同流程。

客戶說：「請購單要顯示價格。」

如果只把它記成欄位需求，就不會碰到另一個更基本的問題：請購的人為什麼需要價格，以及真正對價格負責的人是誰。

這些問題之所以容易被漏掉，是因為企業日常工作本來就容許大量上下文存在。大家知道「這個情況不一樣」，也知道「這個要找某某人處理」，因此不需要把所有規則寫出來。系統則需要更明確的邊界，尤其當它開始限制權限、設定簽核流程、鎖定單據來源或自動帶入資料時，原本可以靠經驗補上的資訊就會變成必要條件。

因此，流程訪談如果只把 happy path 畫完整，最後得到的可能是一條看起來很標準的流程，但真正影響系統設定的 Decision 仍然留在人腦裡。

把口語規則當成假設，繼續找適用範圍與例外

從這次 ERP 導入的幾個案例來看，我覺得可以整理出一個需求訪談階段原則：當使用者描述一條規則時，先把它視為一個需要確認適用範圍的假設。

尤其當對話中出現「全部」、「一定」、「都是」、「從來不會」這類描述時，可以進一步確認最近一次沒有按照這個方式處理的是什麼情況、當時由誰決定、為什麼可以例外，以及如果今天換成一個剛進公司的新人，他能不能只靠現有規則做出相同判斷。

對「所有採購都要請購」而言，需要找的是有哪些採購類型可能不適用；對「新料號需要開發審核」而言，需要確認哪些新料號屬於這個範圍；對「請購單需要價格」而言，則需要確認哪一個角色在什麼階段需要這個資訊，以及他拿到這項資訊之後需要做什麼判斷。

這些追問不一定會立刻產生新的系統功能，但會直接影響後面的 workflow、權限、Master Data 與系統 constraint。如果這一層沒有先釐清，後面即使 ERP 功能都能設定，也很容易把還沒被定義清楚的管理規則固定進系統。

Observe 與 Clarify：先看現場，再把規則說清楚

我目前把 FDE 的工作粗略拆成五層：Observe、Clarify、Decide、Encode、Verify。這次 ERP 導入在需求訪談上的幾個案例，主要落在前面兩層。

Observe 處理的是現場實際怎麼運作。除了訪談使用者，也需要看到他們怎麼操作既有系統、怎麼交接工作、遇到例外時找誰，以及哪些事情其實沒有寫在 SOP 裡。這個階段的目的，是先取得足夠接近真實工作的資訊。

Clarify 則是把這些資訊重新整理成可以討論的規則。哪些是公司正式制度、哪些是某個人的工作習慣、哪些只適用特定品項或客戶、哪些例外其實已經長期存在，以及哪些判斷目前仍然需要依賴有經驗的人。

完成這兩層之後，需求才開始具備比較清楚的邊界，也比較適合進到後面的流程與問題定義。

ERP 導入過程接著也出現了另一種情況。有些問題已經不只是規則還沒問完整，而是公司本身還沒有決定未來要採用哪一種做法。例如採購需求到底要按照每張客戶訂單分開處理，還是把相同料號彙總之後再採購，系統兩種方式都能支援，現場的人卻直接說「我們也還不確定未來的方式會怎樣」。

這類問題就會從 Observe 與 Clarify 繼續往下一層走：當現況已經看清楚，但組織本身還沒有答案時，FDE 還需要協助把真正需要做的 Decision 定義出來。

有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！